After completing this lesson, you'll be able to:
Checking the feature type properties for a dynamic translation reveals the checkboxes that turn on this behavior.
For a reader, all that is required is to check Merge Feature Type:
Unchecking that box turns off the entire behavior, and there are not many parameters to adjust. You can change the Merge Filter to control which feature types FME reads (see the list of wildcards here), but that's about it.
However, for a writer, the dialog is a bit more complex:
You can set the three components of schema - 1) feature type, 2) attributes, and 3) geometry - in different ways.
There are three main components of a schema:
This lesson examines feature types and how a workspace author can change the feature types written in a dynamic translation.
Defining Feature Type Names
In static writer feature types, the feature type name is usually a fixed value. However, you can also define it using an attribute (or string constructed from attributes). We call that a fanout.
Dynamic translations use fanouts automatically. By default, the writer feature type uses an FME attribute called fme_feature_type as the feature type name:
fme_feature_type is an FME attribute that stores the name of the original feature type on incoming features. It makes sense to default to this attribute because all data is written to the same feature type as it came from, and we get an output duplicating the input.
However, should you wish, there's no reason why you can't use a different attribute to define a different set of output feature types:
For example, the author above uses NeighborhoodName to supply the name of the layers to create. Features might have the value Downtown, West End, or Fairview.
FME looks in each Schema Source at runtime to find a Downtown table. It will use the schema of that table to define the attributes and geometry allowed in the dynamic writer's output.
Schema Requirements
Of course, be aware that this isn't the same as a fanout. A fanout creates layers from a static definition. A dynamic workspace fetches that definition from somewhere else (the schema source). Therefore, the feature type names must match a layer in that source schema.
Failure to do so will lead to FME dropping the data - instead of written - with a log message reporting the problem. For example, if the NeighborhoodName attribute had values (like "Downtown" or "Kitsilano") that didn't exist as a table in the schema source, the log would look like this:
FileGDB Writer: A feature with feature type `Downtown' could not be written FileGDB Writer: A feature with feature type `Kitsilano' could not be written
What the author must ensure is that the schema used contains these layers. Then the translation will proceed as expected.
By default, the writer schema in a dynamic translation is defined not in the workspace but by the source dataset. So, whatever dataset you choose as input defines the chosen output structure.
However, the parameters in a writer feature type let us alter how that schema is defined. We can take the structure from an entirely different dataset to the source. Alternatively, we can individually define each component of our schema (Feature Types, Attributes, Geometry) in various ways.
The writer feature type has a dynamic parameter labeled Schema Sources:
This parameter defines where the writer will obtain the destination schema. By default, this parameter uses a source dataset. That way, the output schema always duplicates the input.
However, you can set it to use any reader dataset – in any format – as the source for the outgoing schema.
For example, this workspace author is converting parks data to an Esri Geodatabase but has chosen an Excel spreadsheet as the required structure for the output dataset.
If the data is fanned out (say by NeighborhoodName), then the Excel spreadsheet should have a different sheet for each neighborhood, and the output in this workspace uses that structure as the schema.
Resource Readers
You can set the Schema Source parameter to point to any reader as the source of a dynamic schema. However, in most cases, all we need from the dataset is the schema, not the data.
You can use Resource Readers when you only need the schema of a dataset.
A Resource Reader is a reader that returns the schema of a dataset but no data. You can add one using Readers > Add Reader as Resource on the menu bar:
Here the user adds an Excel spreadsheet database as a resource, and it appears in the Navigator window:
Once available, you can use the resource reader as a schema source for a dynamic writer.
Why Use an External Schema?
The main reason for using an external dataset schema is to adhere to a fixed standard. Perhaps the most beneficial aspect of this is that if the schema of the dataset changes, the workspace automatically uses it. There's no need to update the workspace manually because the output requirements have changed.
However, as noted above, the written data must match that standard or the writer may drop it. So, data transformation is likely required in the workspace to coax the input data into the required output schema.
The SchemaMapper transformer helps reconcile data with the required schema. It can also use an external lookup table, meaning that you can change the dynamic workspace to meet any required output schema without having to edit in Workbench!
